1. Field
The present invention relates generally to computing device debugging. More particularly, this invention relates to providing automatic debugging within a computing device.
2. Background
Debugging techniques exist to generate debug messages to monitor, administer, and troubleshoot computing devices. As an example, debug messages provides system administrators information regarding a problem in the computing device. The information in the debug message may allow the system administrator to identify and resolve the problem (e.g., troubleshooting). Debug messages are generated in a time period known as a debug session. Debug sessions in the prior art must be manually started and stopped. Debug messages are generated continuously during the debug session until the debug session has been stopped.
Typical debugging techniques require a system administrator to determine whether to generate debug messages (e.g., whether to start a debug session) and what module should generate debug messages. The system administrator likely does not want every module to generate debug messages as the amount of debug messages that could be generated by every module may be too large to effectively process (e.g., the system administrator can be overwhelmed with debug messages). Additionally, generating debug messages impacts system performance (e.g., processing load, memory consumption, storage capacity, etc.). Therefore the system administrator desires only to generate debug messages relative to the task at hand. For example in the common case of troubleshooting a problem, the system administrator desires only to generate debug messages relative to the problem.
Choosing which debug messages to generate (e.g., which module should generate debug messages) is not a trivial task for the system administrator. In the case of troubleshooting a problem, typically the system administrator makes a prediction of what the problem is and where (e.g., module, interface, etc.) the problem is occurring. After this prediction, the system administrator configures debug messages to be generated in the computing device where the problem is likely occurring. If this prediction is wrong (e.g., the debug messages do not provide information relevant to the problem) the system administrator configures debug messages to be generated somewhere else in the computing device. By this repeated process of prediction and selective generation of debug messages the system administrator hopes to identify and resolve the problem. In addition to the time and effort it may take the system administrator to complete this process, in the case of a rare problem (e.g, a problem not usually encountered) the system administrator may not be able to locate and resolve the problem regardless of time spent debugging.
In the prior art, debug sessions must be manually started and stopped. One way of manually starting a debug session and limiting the debug messages generated during the debug session is by using filtering debugging techniques. A system administrator manually turns on preconfigured filters in the computing device (thus manually starting a debug session) and debug messages are generated consistent with the filter. As a simple example of a filter, the system administrator may limit the debug messages generated based on a certain Media Access Control (MAC) address. Thus debug messages are generated during a debug session only for that certain MAC address. Another example of a filter is limiting debug messages to a certain interface of the computing device. However, although filtering debugging techniques limit the debug messages generated, filtering debugging techniques have the disadvantage that a system administrator must manually start the debug session (by manually turning on the filter) and manually stop the debug session. Thus, once the administrator has manually started the debug session, debugging messages are generated continuously consistent with the filter consuming valuable system resources (e.g., processing cycles, available memory, storage capacity, etc.) until the system administrator manually stops the debug session (e.g., by turning off the filter).
Additionally, another way of manually starting a debug session and limiting the debug messages generated during the debug session is by using reporting conditionally debugging techniques. A system administrator manually turns on preconfigured reporting conditions in the computing device (thus manually starting a debug session) and debug messages are generated consistent with the reporting condition. A reporting condition may be an event or events that occur within the computing device. For example, a reporting condition may be an authentication failure. Thus, after a system administrator manually starts a debug session (by manually turning on the reporting condition ‘authentication failure’) the computing device generates debug messages for every authentication failure in the computing device. However, reporting conditionally debugging techniques have the disadvantage that a system administrator must manually start the debug session (by manually turning on the reporting condition) and manually stop the debug session. Thus, once the administrator has manually started the debug session, debugging messages are generated continuously consistent with the reporting condition consuming valuable system resources (e.g., processing cycles, available memory, storage capacity, etc.) until the system administrator manually stops the debug session (e.g., by turning off the reporting condition). Additionally, reporting conditionally debugging techniques have the disadvantage that once the reporting condition is met the debug messages cannot be prevented from being generated. Filtering debugging and reporting conditionally debugging techniques may be used together. Using the above examples to illustrate, debug messages are generated upon an authentication failure for a particular MAC address.
Debug messages may be logged either internally and/or externally. Logging debug messages allows a system administrator to examine the debug messages at a later time. Debug messages may be externally logged by any known means of propagating these messages to an external computing device. For example, RFC3164, “The BSD syslog Protocol” (August 2001), may be used to externally log debug messages to an external computing device.
Once the debug messages have been logged, the system administrator may use those debug messages in an effort to locate and resolve the problem. Often the system administrator will use the debug messages in order to recreate the problem on a different computing device. However, recreating any problem is a time consuming process and often rare problems cannot be recreated effectively. For example, in the case of a rare problem encountered on the computing device, the owner of the computing device recognizes that a problem has occurred (although the owner likely does not know the cause of or any resolution of the problem) and notifies the system administrator that something is wrong. As the problem was unexpected and rare, a debug session relevant to the problem likely was not manually started (thus debug messages relevant to the problem probably were not generated). As a system administrator may not be able to resolve the problem without additional information (e.g., debug messages), the system administrator often instructs the owner of the computing device on what to do if the problem occurs again (e.g., the information to gather if the problem occurs again). If the owner of the computing device recognizes the problem again, and is able to gather the information, the system administrator may be able to recreate the problem and resolve that problem with the use of the gathered information. However, the information gathered may not be sufficient to resolve the problem and the system administrator may have to further instruct the owner of the computing device to gather different information. This process is repeated until the system administrator can resolve the problem. As should be understood, the rarer the problem is the more likely that the process will be repeated and a significant amount of time will be spent undertaking this process.